Cache management

Any reasonably good caching strategy will have a remarkable effect on the web site performance. To improve the efficiency of the web site it is recommended to cache as much as possible of the content, to avoid unnecessary server load and data traffic.

Content Studio can control caching on a very detailed level. Content Studio version 4 had a dedicated stand-alone Cache Server to handle this, but from version 5 it relies on the very efficient caching mechanisms that are available in the .NET framework.

When using the administrative user interface, all AS-components using cache mechanisms are disabled, even if they are activated on the web site. It would of course be very difficult to develop the web site if it not was possible to see the result of the changes made. The cache mechanism that translates DocumentID to filename, and the security check for documents in this cache, is also disabled in the administrative user interface.

Cache technology in the Microsoft .NET Framework 2.0

ASP.NET and Content Studio .NET provides a full-featured cache engine that can be used by pages to store and retrieve arbitrary objects across HTTP requests. The ASP.NET cache is private to each application and stores objects in memory. The lifetime of the cache is equivalent to the lifetime of the application; that is, when the application is restarted, the cache is recreated.

The cache provides a simple dictionary interface that allows programmers to easily place objects in and retrieve them from the cache. In the simplest case, placing an item in the cache is just like adding an item to a dictionary:

Cache["mykey"] = myValue;

Retrieving the data is just as simple:

string myValue = Cache["mykey"];
if(myValue != null)
{
   DisplayData(myValue);
}

For more information on the .NET Cache Technology, please visit MSDN at Microsoft.com.

Page Directive with .NET Output Cache

A more generic solution is to use the very efficient cache mechanisms that are available within the .NET framework. They are available through the CacheOutput section of the Document Directives that are found in the Properties and Settings. They can be applied to both categories and documents (HTML or ASPX).

This is where re cache dialog is located:
Documents: File / Document Settings / Document Directive
Categories: Properties / Settings / Document Directive

The OutputCache tab contains a number of settings that directly correspond to the functionality in the .NET framework. There are two mandatory fields:
Duration: Sets the amount of time that a cache entry is to remain in the output cache. The time is measured in seconds. Setting it to zero will imply an infinite duration (until the memory is reused).
VaryByParam: This is a comma-delimited list of query string or form POST parameters that the output cache uses to vary the cache entry. Using an asterisk, all parts of the query string are used for identification. This is a very powerful parameter to customize the cache behaviour.

The Location setting describes where the cache should be located, and the possible values are:

Client: The output cache is located on the browser client where the request originated.
Server: The output cache is located on the Web server where the request was processed.
ServerAndClient: The output cache can be stored only at the origin server or at the requesting client. Proxy servers are not allowed to cache the response.
Downstream: The output cache can be stored in any HTTP 1.1 cache-capable devices other than the origin server. This includes proxy servers and the client that made the request.
Any (default): The output cache can be located on the browser client (where the request originated), on a proxy server (or any other server) participating in the request, or on the server where the request was processed.
None: The output cache is disabled for the requested page.

Components with cache

Some AS-components have settings to cache the data that is returned from the database. These components use the .NET Cache object to store data. Some components have session cache, and therefore use the session variables instead of the .NET Cache object.

If there are several instances of the same component on a page, they will use the same component cache if they have the same identifier (UniqueID) and the same settings/query. If shared cache it NOT suitable between instances of the same component and settings, the identifier must be unique. The first request, outside the administrative user interface, to a page having cached components, will generate the cached data. Subsequent request to the same page will utilize the cached data until it is expired. It is also possible to set the cache timeout limit. The data is stored in a memory pool managed by the .NET framework. If some other applications need more memory, the data in the cache may be released before the intended time limit. Caching pages and data

AS-components supporting cache

Insert document

Supports cache using the application cache in Content Studio (which relies on the .NET Cache Object). The component also uses the DocumentRetrieveCache, if activated in Content Studio settings. For more information on DocumentRetrievalCache, read below(DocumentRetrieveCacheDuration ).

For public pages not using personalization, it is very efficient to activate cache for Insert Document. Examples: page header, footer, menus etc. If caching is activated, and the DocumentRetrieveCache is activated, no database request will be generated by the component.

Insert multiple documents

Insert filtered documents

Supports cache using the application cache in Content Studio (which relies on the .NET Cache Object). The cache mechanism caches the output of the database query – not the generated output of the component. Settings in the component, the query itself, and the identifier of the component is used as unique identifier in the .NET Cache Object.

Script filtered documents

The underlying function CSF_Lookupfield – a method found in the Script Filtered Documents component, also supports cache. The CSF_Lookupfield can be used to get the value for a certain xml-field for a certain document. The syntax for CSF_LookupField:

CSF_LookUpField(CategoryId, LookUpFieldName, RetFieldName, LookUpValue, (UseApplicationCache), (ApplicationTimeOut))

To activate the cache, use the value True in parameter UseApplicationCache, and an integer for ApplicationTimeOut corresponding to the duration of the cache, in minutes.

List pageable filtered documents

Supports cache using the application cache in Content Studio (which relies on the .NET Cache Object). The cache mechanism caches the output of the database query – not the generated output of the component. If paging is used, each page will be cached separately (when requested).

List filtered documents in dropdown

Insert menu 3.0

Caching menus is strongly recommended as they can generate substantial load on the SQL Server. The load is caused by the access checks and other queries applied on all documents in the document hierarchy in the menu.

Caching of User Controls

Caching of User Controls is activated using the OutputCache directive in the User Control. The .NET Framework manages this type of cache.

DocumentRetrieveCacheDuration

When a page in the web site is requested using documentId, Content Studio queries the database to perform an access check and to retrieve the filename of the document. Depending on the type of document and the security settings of the document and the container it resides in, it will generate more or less load on the SQL Server. To decrease the server load, it is possible for Content Studio to cache the access check and the filename. The DocRetrieveCache setting in Content Studio controls this behaviour.

If a value is greater than zero (0), the cache mechanism is activated. The value corresponds to the cache duration in seconds and is applied on all documents in Content Studio that is accessed from outside the administrative user interface. If publishing date (archive date) is used, or if the security settings of the document are changed, the cached data may cause a delayed effect on the web site. The archive date or the new security setting will then not have an effect until the cached data expires. Security settings for Browse (if Windows Authentication is used) and the access check in the file system will not be deactivated by the DocumentRetrieveCache.

In most cases, a DocumentRetrieveCacheDuration of five (5) minutes can be used. A higher value will increase the performance, but further increase the delay of archived documents and changed security settings. Depending on the application/type of website, the value might be as high as 240 minutes.

Multiple layers of cache

For any type of web site, it is possible to use many different types of cache mechanisms to increase performance. For example, caching of a menu system can be done in the menu component Insert Menu 3.0, in the Inserted Page header where component resides, and at page level in which the included page header resides. This type of multiple layered cache mechanisms can cause unpredictable cache results. When the top level cache expires and the underlying included document or component is requested, it may or may not have been cached. In other words, the top level cache may NOT be refreshed because the underlying cache has not expired yet. This will generate longer cache duration at top level (page level).

Multiple layers of cache can be useful in some cases, especially if the cached data or objects can be shared between multiple pages in the web site. Content Studio cannot automatically avoid or solve problems generated from multiple layers of cache. It's up to the developers and architects of the web site to set up cache rules that meets the needs of the customer.

Content Studio settings for Cache

Site settings related to the cache mechanism of Content Studio:

Site settings
Name	Description
Site.DocRetrieveCacheDuration	Document Retrieve Cache Duration in seconds. If value is greater than 0, cache will be used for retrieving documents. This value will affect delays in archive date and publish status.

Caching strategies

There is no “silver bullet” for caching mechanisms. The most suitable settings depend on the site structure, the server capabilities, user load, user patterns and personal opinions. The basic rule is to cache as much data as possible. When deciding if an object should be cached, there are three things that should prohibit you from using the cache:

If the data must be presented “live”, with immediate access to the most recent information. One example could be information from the stock market or an ongoing sports event. Another example could be if settings made by the user should have immediate effect on the web site.
If the data is depending on the settings for an authenticated user. This only affects cache data that is stored on the server or in application variables. Data that is stored locally, in the web browser, could be considered safe to cache.
If the transferred data is expected to be unique almost every time. Then, it would be no performance gain to cache the data.

It is always better to cache a few large objects than many small objects. The best thing is to cache whole pages. If that not is possible, the second best is to cache as many of the included elements as possible. The third level is to cache separate components within a page. This way of thinking not only minimizes the number of objects to cache, it also minimizes the number of requests to possibly cached objects. There are a number of items that always should be considered for caching, because they are used often but seldom changed:

Menus. But put special attention to menus with personalized setting or that are context sensitive (different content depending on the location on the web site).
Activate Content Expiration on the administrative interface (/cs). This is done using the IIS management console, ie. is not managed by Content Studio.
Activate Content Expiration of the ~js folder in the site folder. This is done using the IIS management console, ie. is not managed by Content Studio.
Page footers and page headers.
Web maps and other site overviews
News lists and archives
Edit and presentation templates
Images and other large binary objects.
To find the settings that are optimal, it is necessary to study statistics, server load, server performance and usage patterns. This is specific for each site and may vary over time, so it needs constant attention.

Caching full-text search results

Do not use the application cache in components used for full-text searching the web site. As users may use ANY search query, the application cache will be full and cached data will expire very quickly making the application cache almost useless.